DevOps - An executive summary by Neil S. Meyer

Author:Neil S. Meyer [Meyer, Neil S.]
Language: eng
Format: azw3
Publisher: anonymous
Published: 2017-03-15T04:00:00+00:00

In-house capabilities

Much of the benefits of moving to DevOps are around the principles of working smarter, not harder. One of the first superstar DevOps engineers (yes - I’ll come onto titles later) described good DevOps practice as follows:

It’s when a talented, but easily bored engineer, finds ways to automate as much as she reasonably can to make her day to day work more interesting and beneficial to the whole delivery.

I like that view, as it captures the spirit of automation over manual effort in a very understandable human way.

While most people should be capable of understanding the benefits of adopting DevOps, some engineers will continue to want to work in the same way that they have always worked, and some will find retooling difficult. At some stage you will need to consider whether everyone is part of the change, or whether their traditional outlooks are best suited outside of your organisation.

For those that are keen to make the change, and are technically able to do so, there are many vendor led courses available via online resources or through directly contacting the vendors and asking for advice. Self training is fine for those that are self motivated and who learn well that way, however it’s not for everyone.

Another option is to supplement your in-house team with experienced contractors who are already proficient with the tools and DevOps way of working. Here you are looking to find contractors who are able to also train and inspire. It’s of very little benefit to have a high cost rockstar contractor come in, set everything up and leave, only to find that nobody actually knows how to operate the environments going forward.

Another useful way to promote the change with in-house teams is to provide them with the time and resources to explore and research tools and approaches. I have worked in organisations that ran internal ‘hack days’ where the nature of the day was to explore new things in a collaborative way, with shared learnings thereafter.

You may also very well find talented enthusiasts within your own team, who may be trying these new tools in their spare time. In my opinion these are very possibly the true 'diamonds in the rough', those that should be given support and room to contribute. Note, however, that the important word is ‘talented’, not just someone who is able to list the tools but hasn’t really evaluated or played with them in any meaningful way.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.